1. Field of the Invention
This invention relates to improved systems and methods for controlling the execution of one or more computer application programs on one or more host computers under the control of a second computer, without changes to any of the pre-existing host application programs.
2. Description of the Prior Art
Since the early days of digital computers, the problem of asynchronous distributed computing has proven difficult to solve in spite of many attempts. In 1978, C.A.R. Hoare of The Queen's University of Belfast, Northern Ireland, in a paper titled "Communicating Sequential Processes", attributes the difficulty of building such distributed applications to the complexity of programming nondeterministic systems. The coding complexity of such problems, although well known in academic circles, remains to this day largely unrecognized in the computing industry at large. Presently, most of the tools and enabling technologies provided to address the problem of distributed computing do not even recognize this as an issue.
On the other hand, synchronous distributed systems do not have to address the problem of non-determinism, and therefore are less complex to build. Such systems do not, however, live up to the expectations of distributed computing in terms of performance, ease of use or maintenance costs. For this reason there continues to be a succession of new products introduced more or less continuously which claim to provide a practical solution to asynchronous distributed applications. Many such products, although introduced by very large and experienced corporations having large marketing capabilities, such as IBM's SAA architecture and relational DBMS client/servers, DEC's X-windows, OSF's foundations ORB architecture, and others, by failing to address the problem of non-determinism, have achieved only limited success. More recently, a new class of products characterized as "three tier middleware", such as CORBA (Common Object Request Broker Architecture)from OMG and DCOM from Microsoft, claims to provide a practical solution to the problem, but fails to take into account that such products increase the level of complexity, since they introduce non-determinism at both sides of the middleware.
By definition, middleware products act as intermediary between different resources in a computer system. Originally, the concept of middleware was applied to network integration, providing network access between similar (bridges) or different (gateways) networks. For example, a network gateway acts as an intermediary between two different networks such that neither network needs to be modified in order to operate jointly. FIG. 1 shows the functions of a network between client functions and server functions.
Proliferation of different software applications that provide similar services but which exist on different computer systems, e.g. electronic mail systems such as PROFSs (Professional Office System), and Office Vision on IBM systems, All-in-One on DEC mainframes, and Microsoft Mail on Windows systems) has created the problem of how to integrate such applications into a single system. The obvious solution was to extend the concept of middleware from integrating networks to the integration of applications software.
However, this turned out to be very difficult to do in the absence of a program interface. Unlike a user interface, which allows a human to access the services of a computer program, a programmatic interface permits one computer program to request the services of another computer program. As a result, many computer programs are now offered with such an interface, commonly called an API (Application Program Interface). Some such APIs have become "standards", but many more are used by only one such application. For example, X.400 and X.500 are "standard" APIs for electronic mail systems, while Apple's OCE and Microsoft's Mail interface are examples of proprietary interfaces.
The recent proliferation of APIs, from Internet's APIs such as HyperText Transfer Protocol (HTTP), Hyper Text Markup Language (HTML) and MIME, to Client/Server APIs such as SQL, ODBC, and up to mainframe APIs such as APPC, X.500 and others, has made the integration of computer applications even more involved than it was before their introduction. In order to accommodate these various APIs, middleware products have become more and more complex. Unlike the evolution of network protocols, which has seen a convergence over time to a limited number of standards such as Ethernet, Token Ring, TCP/IP, IPX and SNA, the growth of APIs continues due to the increase in complexity of computer applications services. This proliferation and evolution of APIs is reflected in a corresponding proliferation and evolution of middleware products.
Most middleware products today provide solutions for a limited set of such APIs depending on the market need and opportunity. For example, there are middleware products that convert SQL requests to CICS transactions only, and middleware products that convert HTPP transactions to ODBC requests only. The rapid growth in computer services applications, which is reflected in the rapid development of APIs, has often made such middleware products obsolete even before the integration projects have been completed.
Middleware is positioned between different components and resources of a computer system that communicate with each other. As the minimum, middleware must be able to receive and transmit messages and to act as a message dispatcher. Middleware products that do not modify messages are called bridges: M/Q middleware from IBM, and DEC message Q are examples of such products. Most such bridges provide routing capabilities, message queuing and monitoring, guaranteed deliveries, etc., between dissimilar computer systems and networks. However, the applications components sending and receiving messages in this environment must use the same messaging system. FIG. 7 shows the manner in which an application bridge manages messages by queuing and redirecting them from one system to another without any changes to any message. In this model, the Application A-1 may communicate with Application A-2, but not with Applications B-1 or B-2, which happen to use a different communication system. FIG. 8 differentiates an application gateway from an application bridge of FIG. 7 by its ability to interpret and translate messages from one messaging system to another, which results in the ability of Applications A-1 and A-2 to communicate with Applications B-1 and B-2 without requiring changes to any of these applications.
Most known middleware products support a tightly coupled model for distributed systems. Such a model requires that all parts of a distributed system be developed using a pre-defined communication system or API. As result, any changes to any module require modifications to other modules, and changes to the communication system (API) may require extensive changes to all modules. Recent products, such as Entera from Open Environment Corp. (OEC), OMG's CORBA, Sun's RMI and Microsoft's DCOM, exemplify this model by proposing a "standard" for building distributed applications.
Typically, each such "standard" is incompatible with the others, and applications developed under any such "standard" will be unable to communicate with any application not using it. The backbone of such a system is usually a middleware product developed to carry out the "standard". Each module relies on the middleware to provide a variety of services, from connectivity, to message routing, data encryption, etc. This variety of services is more typically associated with an operating system than a middleware product. As a result, applications developed under such a system are very dependent on the middleware and therefore even more insulated from integration with the services of other systems.
The aim of such bridging middleware strategy is to permit integration of various hardware components, such as mainframes from IBM, minicomputers from DEC, servers from HP and workstations from SUN, under a single system. This strategy, however, precludes integration of various software applications developed under different systems.
U.S. Pat. No. 5,228,137, ("the `137 patent") on which the present application is based and which is incorported herein by reference, teaches, inter alia, a method of re-establishing determinism for a developer attempting to construct a computer program that integrates one or more remote computer programs which are running in remote host systems. The `137 patent describes how, by using an intermediary layer of software, generically called middleware, a developer may build a computer program that synchronously controls the execution of one or more remote programs in a deterministic fashion. The middleware in this case functions to restore the determinism by resolving the problems of non-determinism.
The `137 patent also discloses a method for controlling the execution or one or more remote computer applications programs under the control of a second computer system. Implicit to the system of that patent, as shown in FIG. 2, is a software apparatus, commonly called a framework, which implements most of this method and as a result of its use, reduces the work required by a user to complete the process of remotely and simultaneously controlling other computer applictions programs residing in one or more different host computers.